More Related Content
Similar to AWSへのシステム移行に伴う クラウドマインドへの移行 (20)
More from Mitsuhiro Yamashita (20)
AWSへのシステム移行に伴う クラウドマインドへの移行
- 10. 自己紹介も兼ねてクラウドと自分のなれそめを
25年間
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
- 11. 自己紹介も兼ねてクラウドと自分のなれそめを
25年間
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
調達スピー
ド
提供スピー
ド
コスト最適化 予測不可能
- 12. 自己紹介も兼ねてクラウドと自分のなれそめを
25年間
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
調達スピー
ド
提供スピー
ド
コスト最適化 予測不可能
必要な量を、必要なときに、
人の手を介さず調達して、
使った分だけ請求、
世界中のどこでも使える
- 13. 自己紹介も兼ねてクラウドと自分のなれそめを
25年間
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
- 21. 自己紹介も兼ねてクラウドと自分のなれそめを
開発方法の遷移
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
アジャイルソフトウェア開発宣言、SOA
- 47. Architecting for Cloud
Loose Coupling
コンポーネントを疎結合にする
Removing Single Points of Failure
単一障害点を排除する
Scalability
スケーラビリティを確保す
る
Automation
自動化して信頼性を高める
Services, Not Servers
サーバーではなく、サービスで設計
Optimize for Cost
コストの最適化
Disposable Resources
リソースを使い捨てする
Databases
適切なデータベースを選択する
Managing Increasing Volumes of Data
増え続けるデータを中心で管理
Caching
キャッシュを使う
Security
すべてのレイヤーにセキュリティ
- 61. 自己紹介も兼ねてクラウドと自分のなれそめを
25年間
20201995 2000 2005 2010 2015
Amazon.com
Google検索 Wikipedia
Skype
Facebook
YouTub
e
Twitte
r
Instagram
SlackLINE
Client Mobile client Smart Phone
FireTVEcho
Sensor
Action
CarHouse
Bicycle Door lock Factory
Editor's Notes
- RFPはこれ
- 1995年amazon.com, 1998年Google検索、2001年Wikipedia, 2003年Skype、2004年Facebook, 2005年YouTube, 2006年Twitter, 2010年Instagram, 2011年LINE, 2014年Slack、他には1996年にYahoo検索、2006年にUstreamなど
- 1999年Docomoさんのiモード、2007年iPhone、
ユーザーがコンテンツを作ってビジネスが成り立つ、多くのアクセスを可能とした、
提供するためにはハードウェアを調達していては追いつかない
- 具体的なエンジニアリングにおける課題とメリットのお話がありましたが、ビジネスの課題は?
スピードを早めなければならない、利用量が大きく変動するのでインフラも無駄なく変動させたい、ユーザーの口コミなどにより爆発するのでいつビジネスが急成長するか予測がつかないので固定で持てない、インターネット回線の進化によりユーザーに提供するスピード(パフォーマンス)で売上に差が出るようになったのでユーザーに近い場所に構築
ハードウェアからソフトウェアへ、所有から利用へ
- インターネットの普及、マルチデバイス化、により生まれた課題に対して、解決しているのがクラウドコンピューティング
- 2006年にAWS誕生
- AWSの6つの強みとメリットもその課題解決によるメリット
- 2006年1つから
- 2014年のJAWS DAYS のTシャツバックプリントの全サービス
- 2001年にアジャイルソフトウェア開発宣言 2004年頃からサービス指向アーキテクチャ
ウォーターフォールでは仕様確定後の追加ニーズをブロックしていたため、開発結果が時代のニーズに追いつかない課題があったが、決めごとよりも柔軟性を重んじる開発方法への変遷により追加ニーズを受け入れることが可能になり、それによるビジネスの拡大が始まった。
Amazonもお客様の要望を聞きながら様々なサービス拡大を続けている。
AWS自身も95%以上は顧客ニーズとありましたがそれを受け取りながら拡大している。
- なので増え続けるし今でも増え続けている。
- これだけのサービスがあるのに、一つのサービスしか使わないのはメリットを活かしきれないかも。
- まずはリフトとして持っていくだけでもいい。
- OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- EC2インスタンス、こんなに常時稼働?
オンプレミスでは常時稼働があたりまえ。
- スケーラビリイティを確保し、かつ、リソースを使い捨てに
- 先程は1/5になった例ですが、この例ではわりと多いインスタンスが必要な6割ぐらいは使う例です。最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。
オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。
オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。
オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- さらに割引ができます。このオプションがあることはもちろん隠してもなければ使い始めるときに基本的には説明もありません。最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。
オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- 画像も全部EC2を使ったwebサーバーから配信している
- 画像や静的なファイルはS3から配信
ECなどコンピューティングリソースでは計算処理だけを行い、使い捨てにする
- データベースは何がなんでもRDBMS
- NoSQL, データウェアハウス、キャッシング、適したデータベースサービスを使い分ける
- CloudFrontでキャッシュを持つ
- 非同期でいい処理はLambdaにまかせる
EC2とLambdaはSQSで疎結合しお互いが影響を受けにくくする
- 最適化の継続のためにはどうするか?今日来られた方々はいろいろ勉強されています。でもみなさんが全部対応するわけにはいきません。
チームメンバーみんなが変わる必要があります。ではどうしますか?Architecting for Cloud読みましょう
- Well-Architected Framework読みましょう
それだけで人が動くわけがない。
- なぜ、自律組織がいいか
クラウドのメリットの一つはスピードです。
そのスピードを活かす組織かボトルネックになる組織か。
判断する人が少ないとボトルネックになります。
- 自分で考え自分で動く組織が必要になります。
統制よりも自立です。
何を移譲して何を統制するか、この判断は相手への思いやり。
これを移譲して責任をもたせるのは酷なのではないか、そういうものは統制対象にして承認とする。
それ以外は移譲する。
- 移譲して発生する失敗を歓迎する。
失敗のない組織に成功はない。
そもそもやらないと成功か失敗かなどは分からない。
人にやらされた失敗は人のせいにする、自分で判断した失敗は自らチャンレジする
- 昔はわかった。なぜなら経験者がいて、その経験したことと同じことをするから。なので経験者は承認者となり新たな実行者が経験者に指示を仰ぎながら実行する。実行者がそのうち承認者となり判断をする役割になる。世の中はそれでうまくまわっていたけどそれはもう破壊された。
- 今は「やってみないと分からない」をやる時代。
だからそもそも承認が意味をなしていない場合も多い。
意味をなさない承認のために、専門家でもない承認者に説明する、そのための資料作りに忙殺され、ビジネスへの貢献などまったくできない状態に陥る。
クラウドのメリットをまったく活かせていないといえる。
- ちなみにもう一つのパターン。
やらなくていい。誰かが作るって指示を出せばできる。
- チームに移譲して判断できるようにするためには、思いを伝え続けることも大切です。
理念やクレド、行動規範など、大枠のコンテンツもあったほうがいい。
そしてそれに対しての思いを伝える。伝え続ける。
そして黙ってやらない。何考えているか分からない人とは仕事はできない。
心の方向指示器
メンバーが安心して判断できる環境を作る。
- 判断するためには技術も知識も必要。
インプットは常に行う。
組織はチームメンバーのインプットを支援する。
大切なのはアウトプットありきでインプットすること。
そのアウトプットには外のものさしも使う。
- 外部に知人が増えてつながるとSNSに欲しいインプット情報が向こうから入ってくるようになる
どの段階においても必ずリアクションをする。
否定しない。ダメ出ししない。アドバイスする。
じゃまをしない。マウントしない。
無反応は一番の悪。
外のフィルターをとおって社内に伝わると、勝手にエビデンス付きの評価になる。
- 35歳前後でなんとなく勉強しなくなりました。
やらなくなるとそれが当たり前になってしまって、ベンダーさんの言うことが正しい、経営層の判断がすべて、が当たり前と錯覚して考えない。
自社に特化したものしかやらない。新しい技術も学ばない。
新しい技術を使うことで今まで得てきた経験が無駄になるのでは。
ではなくて、今までの経験を本当に無駄にするか、価値あるものにするかは自分次第。
そのためには知るしかないし、学ぶしかない。
そうすることで今までの経験や知見が必ず生きてくる。
権限移譲も一つの危機感をもつきっかけになることはあるが、追い詰めないよう注意が必要。
- 35歳前後でなんとなく勉強しなくなりました。
やらなくなるとそれが当たり前になってしまって、ベンダーさんの言うことが正しい、経営層の判断がすべて、が当たり前と錯覚して考えない。
自社に特化したものしかやらない。新しい技術も学ばない。
新しい技術を使うことで今まで得てきた経験が無駄になるのでは。
ではなくて、今までの経験を本当に無駄にするか、価値あるものにするかは自分次第。
そのためには知るしかないし、学ぶしかない。
そうすることで今までの経験や知見が必ず生きてくる。
権限移譲も一つの危機感をもつきっかけになることはあるが、追い詰めないよう注意が必要。
- 1995年に戻れたら何をしますか?
- 私は本はあげる派です(入社祝いや誕生日祝い)。チームや組織が本一冊でよくなるなら安いものです。
自分が欲しい本も誕生日にもらえたりもするので結果OKだったりも。
- 良かれと思ってでも手とり足とり教えられると、自律は失われます。
気づきのためのインプットと、それを使える環境や権限、そしてアウトプットの環境を提供する。
必要に応じて人事制度でインセンティブ。
- 認定資格は提案や設計、構築、開発など仕事を任せていただくためのエビデンス。
たとえば今日私がしたお話が、認定資格を持っていない人が話していたら、「本当かな?」ってなる方もいらっしゃいます。
人事部門担当の方はどの資格がどれぐらいのことができるか、価値があるかぐらいは抑えておいたほうがいいです。
- 通算100日登壇、受講者数844名